This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of 
the original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 

• BLACK BORDERS 

• TEXT CUT OFF AT TOP, BOTTOM OR SIDES 

• FADED TEXT 

• ILLEGIBLE TEXT 

® SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 

• GRAY SCALE DOCUMENTS 

IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents mil not correct images, 
please do not report the images to the 
Image Problem Mailbox. 



per 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification 5 ; 

G06F9/46 



Al 



(11) International Publication Number: 
(43) International Publication Date: 



WO 94/11817 

26 May 1994 (26.05.94) 



(21) International Application Number: PCT/US93/I0854 

(22) International Filing Date : 9 November 1 993 (09. 1 1 .93) 



(30) Priority data: 

07/974,959 



9 November 1992 (09. 1 1 .92) US 



(71) Applicant: MICROSOFT CORPORATION [US/US]- 

One Microsoft Way, Redmond, WA 98052-6399 (US). ' 

(72) Inventor: ATKINSON, Robert, G. ; 17926 NE 196th 

Street, Woodinvilie, WA 98072 (US). 

(74) Agents: PIRIO, Maurice, J. et al.; Seed and Berry, 6300 
Columbia Center, 701 Fifth Avenue, Seattle. WA 
98104-7092 (US). 



(81) Designated States: CA ; JP, KR, European patent (AT, BE, 
CH DE, DK, ES, FR, GB, GR, IE, it" LU, Mc/nL, 
PT, SE). 



Published 

With international search report. 

Before the expiration of the time limit for amending the 
claims and to be republished in the event of the receipt of 
amendments. 



(54) Title: METHOD AND SYSTEM FOR CONNECTING OBJECTS IN A COMPUTER SYSTEM 



(57) Abstract 

Method and system for connecting link object to a link 
source. In a preferred embodiment, a source process registers 
the link source in a running object table when the link source 
enters a running state. When a consumer process subsequently 
puts a container object containing the link object in a running 
state, the consumer process determines if the link source is re- 
gistered in the running object table. If the link source is regis- 
tred in the running object table, then a connection is established 
between the link object and the link source. If, however, the link 
source is not registered, then the consumer process registers the 
link object in an alert object table. When a source process sub- 
sequently puts the link source in the running state, the source 
process determines if the link object is registered in the alert ob- 
ject table. If the link object is registered in the alert object table, 
then the source process notifies the link object and a connection 
is established between the link object and the link source. 
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Descript-^ nn 

METHOD AND SYSTEM FOR CONNECTING OBJECTS 
IN A COMPUTER SYSTEM 

Technical FiPlrl 

This invention relates generally to a computer 
method and system for updating objects with new 
information, and more specifically, to a method and system 
for connecting a link object to its link source without 
explicitly activating the link object. 



Background of the Invention 

Current document processing computer systems 
15 allow a user to prepare compound documents. A compound 
document is a document that contains information in 
various formats. For example, a compound document may 
contain data in text format, chart format and/or numerical 
format. Figure ia is an example display showing a 
20 compound document. The compound document 101 contains 
text data 102 and 103 and spreadsheet data 104. 

Figure IB is a block diagram showing a file 
layout of the compound document shown in Figure 1A. The 
file "compound.doc" ill contains data blocks 112 and 113 
25 containing the text data and data block 114 for storing 
the spreadsheet data. The data block 114 contains the 
spreadsheet data in a presentation format 116 and a link 
115 to a file 117 that contains the spreadsheet data. A 
presentation format is a format in which data is easily 
30 displayed on an output device. For example, the 
presentation format may be a bitmap that can be displayed 
with a standard block transfer operation such as a BitBlt. 
The file ill contains the spreadsheet data in presentation 
format so that the file 117 does not need to be accessed 
35 every time the compound document is displayed. The link 
115 points to the file 117 where the spreadsheet data is 
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stored in a native format. a native format is a format 
that is recognizable by the program that created the file. 

Figure 2 shows a method for creating a compound 
document. A user generates the spreadsheet data 206 using 
5 spreadsheet process 205. The spreadsheet process 2 05, 
typically under user control, then stores the spreadsheet 
data 206 in a presentation format (presentation data) and 
a link' (pointer) to the native spreadsheet data in a 
.clipboard 207. The clipboard 207 is an area of storage 
10 (disk or memory) that is typically accessible by any 
process . 

Next, the user launches a word processing 
process 204 to create the compound document 201. The user 
enters text data 202 and specifies a location in the 
compound document 2 01 at which to insert the data in 
clipboard 207. The word processing process 204 then 
copies and stores the presentation data and link from the 
clipboard 207 and displays the spreadsheet data using the 
copied presentation data in the compound document 201 at 
the specified location. This insertion process is 
referred to as "paste linking" from the clipboard. Data 
that is paste linked into a compound document is referred 
to as linked data. 

A process which stores data in a clipboard is 
25 called a source process. A process which copies data from 
the clipboard is called a consumer process. In the 
present example, the spreadsheet process 205, which stores 
data in clipboard 207, is a source process, and word 
processing process 204 is a consumer process. Typically, 
3 0 a single process acts as both a consumer and source 
process at different times. 

In object-oriented parlance, any collection of 
data or functions is referred to as an object. Thus, 
compound document 201, spreadsheet data 206, spreadsheet 
35 data 203, and text data 202 are objects. Also, an object 
that is contained within another object is referred to as 
a contained object within a container object. Spreadsheet 
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data 203 is a contained object within compound document 
2 01, which is a container object. An object that contains 
a link to native data is a link object. An object that a 
link object points to is a link source. In Figure 2, 
spreadsheet data 2 03 is a link object and spreadsheet data 
206 is a link source. 

Prior systems typically allow a user to 
establish a connection between a link object and its link 
source so that modifications to the link source can be 
reflected when the container object of the link object is 
displayed. To establish a connection, the user instructs 
the consumer process to activate the link object. The 
consumer process activates the link object by starting the 
source process and establishing a connection with the 
15 source process using standard operating system 
interprocess communication mechanisms in response to user 
selection. Through this connection, the source process 
notifies the consumer process when the link source has 
been modified. The consumer process can then modify its 
presentation data to reflect the modifications in the link 
source. Thus, when a connection is established between 
the link object and its link source, the presentation data 
in the link object accurately reflects modifications of 
the link source data. 

In certain situations, prior systems allow link 
source data to be modified without modifying the consumer 
process presentation data. Thus, the link source data and 
presentation data can be inconsistent. A user can start 
the source process, open the link source, and display and 
modify the link source data. if the user then starts the 
consumer process, opens the compound document, and 
displays the presentation data, the displayed presentation 
data will be inconsistent with the displayed link source 
data. Since the source process was not started as a 
35 result of activating the link object, there is no 
connection through which consistency can be maintained. 
This inconsistency is undesirable. 
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Summa ry of the Invention 

It is an object of the present invention to 
provide a method and system for automatically connecting a 
link source to a link object. 

It is another object of the present invention to 
provide a method and system wherein the connection is 
established when the link source does not enter a running 
state through activation of the link object. 

These and other objects, which will be apparent 
as the invention is more fully described, are provided by 
a method and system for automatically connecting a link 
object to a link source. In a preferred embodiment, a 
source process registers the link source in a running 
object table when the link source enters a running state. 
When a consumer process subsequently puts a container 
object containing the link object in the running state, 
the consumer process determines if the link source is 
registered in the running object table. If the link 
source is registered in the running object table, then the 
consumer process can establish a connection between the 
link object and the link source. Alternatively, when a 
consumer process puts a container object of the link 
object in the running state and if the link source is not 
in the running object table, the consumer process puts the 
link object in an alert state and registers the link 
object in an alert object table. When a source process 
subsequently puts the link source in the running state, 
the source process determines if the link object is 
registered in the alert object table. If the link object 
is registered in the alert object table, then the source 
process notifies the link object. The link object can 
then establish a connection between the link object and 
the link source. 
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Brief Description of the Drawing 

Figure 1A is an example display showing a 
compound document . 

Figure IB is a block diagram showing a file 
5 layout of the compound document shown in Figure 1A. 

Figure 2 is a block diagram illustrating a 
method for creating a compound document. 

Figure 3 is a diagram showing a preferred 
computer system. 

10 Figure 4 is a block diagram of a preferred 

embodiment of an alert object table. 

Figure 5 is a block diagram of a preferred 
embodiment of a running object table. 

Figure 6 is a block diagram illustrating 
15 automatically making a connection between a link object 
and a source object. 

Figure 7 is a flow diagram of a process acting 
as a consumer and source . 

Figure 8 is a flow diagram of the function 

20 Register. 

Figure 9 is a flow diagram of the function 
BeginRunning. 

Figure 10 is a flow diagram of the function 
RegisterlnROT. 

25 Figure li is a flow diagram of the function 

RegisterlnAOT. 

Figure 12 is a flow diagram of the function 

Revoke . 

30 Detailed Descript ion nf the Invention 

The present invention provides a method and 
system for automatically connecting link objects to their 
link sources without explicitly activating the link 
objects. When a compound document is put in a running 

35 state by a consumer process, each link object contained in 
the compound document is put in an alert state and 
registered in an alert object table (AOT) . If at a later 
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time a link source is put in a running state by a source 
process, the link source is registered in a running object 
table (ROT) and the alert object table is scanned to 
determine whether any corresponding link objects are 
5 registered in the A0T awaiting notification of the running 
of the registered link source. If a corresponding link 
object is registered, then the source process notifies the 
link object. The link object then directs the consumer 
process to establish a connection between the link object 

10 and the link source, using standard interprocess 
communication techniques. If the source process modifies 
the link source data after the connection is established; 
then the modifications are reflected in the presentation 
data associated with the link object. 

15 If/ instead, the link source is put in the 

running state before a corresponding link object is put in 
an alert state, then the processes operate in a slightly 
different manner. Specifically, when the source process 
puts the link source in the running state, the link source 

20 is registered in the running object table (ROT) . If at a 
later time a compound document that contains a link object 
is put in the running state by a consumer process, then 
the link object enters the alert state and the ROT is 
scanned by the consumer process to determine whether any 

25 corresponding link sources are registered in the ROT. If 
a corresponding link source is registered, then the 
consumer process establishes a connection between the link 
object and the link source, using standard interprocess 
communication techniques. If the source process modifies 

30 the link source data after the connection is established, 
then the modifications are reflected in the presentation 
data associated with the link object. 

Figure 3 is a block diagram illustrating a 
computer system in which the present invention is 

3 5 preferably implemented. Computer system 3 00 comprises 
computer memory, a central processing unit, storage 
devices, and input /output devices. The input /output 
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devices include a display, a keyboard, and a mouse. The 
alert object table 3 01, running object table 3 05, and 
computer instructions and data for the consumer process 
302 and source process 306 are stored in the computer 
memory. The computer instructions are executed under the 
control of the central processing unit. The compound 
document 303, which contains link object 304 and the link 
source 307, is stored on a storage device, such as a disk. 
The consumer process 302 and source process 306 load 
portions of the compound document 303 and link source 307 
into the computer memory for processing. Although 
preferred embodiment is described as being implemented on 
a standard computer system, one skilled in the art would 
recognize that the present invention could also be 
implemented on computer systems with other architectures. 
For example, the present invention can be implemented on a 
multiprocessor computer system or a computer system 
comprising multiple computers. 

In a preferred embodiment, an object can be in 
the following states: passive, loaded, running, and 
alert. An object is in the passive state when it is 
stored only on disk. An object is in the loaded state 
when its object structure is loaded into the memory of a 
consumer process. An object is in the running state when 
the source process for the object is running and the 
object data is available to the source process. An object 
is in the alert state when it is awaiting notification 
that another object has entered the running state. 

In the following, a pointer to an object 
represents the address of an object in the loaded state. 
The object can be accessed using this pointer. An 
identifier of an object represents a unique identification 
of the object regardless of its state. Thus, a link 
source identifier identifies an object that may be in the 
35 running state, passive state, etc. In a preferred 
embodiment, each object has an associated function that 
returns the pointer to the object. If the object is not 
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already in the loaded state, the function puts the object 
in the loaded state and returns the pointer. A pointer 
and an identifier are referred to generically as 
references . 

5 A preferred embodiment of the present invention 

uses two primary data structures: an alert object table 
(AOT) and a running object table (ROT) . The alert object 
table is used to register link objects in the alert state, 
which are to be connected to link sources when the 

10 corresponding link sources enter the running state. 
Figure 4 is a block diagram of a preferred embodiment of 
the alert object table. Each row of the alert object 
table corresponds to a link object in the alert state and 
contains two items of information: a link object 

15 identifier 401 and a link source identifier 402. The link 
object identifier 401 uniquely identifies a link object 
that is in the alert state. For example, the link object 
identifier for spreadsheet object 203 (Figure 2) could be 
the string "PID\compound.doc\objectl . " The "PID" 

2 0 indicates the consumer process identification and 
"\compound.doc\objectl n identifies the object within the 
compound document. Link source identifier 402 uniquely 
identifies the link source. For example, the link source 
identifier for spreadsheet object 206 could be string 

25 "c:\spreadsheet.xls," which identifies the location of the 
spreadsheet file. If, instead, the link source was a 
specific range within the spreadsheet, the link source 
identifier could be string "c:\spreadsheet.xls\range 
R1:C1-R3:C3, M where the "range Rl : C1-R3 : C3 " identifies an 

30 object within the spreadsheet file. Once information has 
been stored in the alert object table, a source process 
can scan the AOT to identify which link objects need to be 
notified. In an alternate embodiment, the alert object 
table stores a link object pointer rather than a link 

35 object identifier. 

The running object table is used to register 
link sources that are in the running state. Figure 5 is a 
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block diagram of a preferred embodiment of the running 
object table. Each row of the running object table 
corresponds to a source object in the running state and 
contains two items of information: a link source pointer 
501 and a link source identifier 502. The link source 
pointer 501 points to an instance of the link source 
object in the running state. Link source identifier 502 
uniquely identifies the link source as discussed above 
with reference to the alert object table. 

Two examples using Figure 6 will help illustrate 
operation of the present invention. The first example 
depicts the present invention when a link source is put" in 
the running state after a corresponding link object is 
registered in the alert object table. The second example 
15 depicts the present invention when a link source is put in 
the running state before a corresponding link object is 
registered in the alert object table. 

In the first example, a user starts word 
processing process 604 and opens compound document 601, 
which puts the compound document in the running state. 
The word processing process 604 determines that a 
contained spreadsheet object 603 is a link object and 
contains a link source identifier which identifies the 
spreadsheet object 605. The word processing process 604 
retrieves the link source identifier and scans the running 
object table 608 to determine if spreadsheet object 605 is 
in the running state. Since the spreadsheet object 605 is 
not in the running state, there is no entry in the running 
object table 608 matching the retrieved link source 
30 identifier. Word processing process 604 then registers 
spreadsheet object 603 in the alert object table 607. 
This registration process stores in the alert object table 
the link object identifier of the spreadsheet object 603 
and the link source identifier of the spreadsheet object 



20 



25 



35 605 



When the user starts the spreadsheet process 606 
and puts spreadsheet object 605 in the running state, the 
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spreadsheet process 606 registers spreadsheet object 605 
in the running object table 608. This registration 
process stores the link source pointer and the link source 
identifier of the spreadsheet object 605. 
5 Once spreadsheet object 6C5 is registered, 

spreadsheet process 606 scans the alert object table 607 
to determine if any link objects are registered as 
awaiting notification that spreadsheet object 605 is in 
the running state. After determining that the spreadsheet 

10 object 603 is registered as awaiting notification from the 
spreadsheet object 605, the spreadsheet process 606 
notifies the spreadsheet object 603, The spreadsheet 
object 603 then directs the word processing process 604 to 
establish a connection between link spreadsheet object 603 

15 and source spreadsheet object 605 so that modifications 
made to spreadsheet object 605 are reflected in the 
presentation data of spreadsheet object 603. 

In the second example, again using Figure 6, a 
user opens a compound document containing link spreadsheet 

20 object 603 after the corresponding source spreadsheet 
object 605 has been registered in the running object table 
608. Once again, compound document 601 has been created 
such that spreadsheet object 603 is a link object and 
contains a link source identifier to spreadsheet object 

25 605. 

Before opening the compound document, the user 
starts the spreadsheet program 606 and opens the 
spreadsheet object 605. When the user opens spreadsheet 
object 605, the object enters the running state and is 

30 registered in the running object table 608. The 
registration process stores the link source pointer of the 
spreadsheet process 606 and the link source identifier of 
the spreadsheet object 605. 

Once spreadsheet object 605 has been registered, 

35 spreadsheet process 606 scans the alert object table 607 
to determine if there are any obj ects registered in the 
alert object table 607 awaiting notification of the 
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running of spreadsheet object 605. In the present 
example, spreadsheet process 606 finds that no objects are 
currently awaiting notification of the running of 
spreadsheet object 605. 
5 Later, when the user starts up the word 

processing process 604 and opens the compound document 601 
(which puts the compound document in the running state) , 
and then opens spreadsheet object 603, the word processing 
process 604 determines that the spreadsheet object 603 is 

10 a link object corresponding to link source 605. The word 
processing process 604 then scans the running object table 
608 and determines that spreadsheet object 605 is in the 
running state. Word processing process 604 then connects 
spreadsheet object 603 to spreadsheet object 605 so that 

15 modifications to spreadsheet object 605 are reflected in 
spreadsheet object 603. 

In a preferred embodiment of the present 
invention, an optimization can be made to make the running 
object table smaller and more efficient. Specifically, in 

20 either example discussed relative to Figure 6, the 
spreadsheet process 606 only registers spreadsheet object 

605 in the running object table 608 when there is a 
possibility that a compound document may contain a link to 
the spreadsheet 605. Otherwise, if no possibility exists, 

25 there is no need for an entry in the running object table. 
To implement this optimization, the spreadsheet process 

606 keeps track of any links requested from it. For 
example, the spreadsheet process 606 can record this 
information when it is requested to place data in 

3 0 presentation format on the clipboard with a link source 
identifier. The spreadsheet process 606 can then store 
this information in the link spreadsheet object 605. When 
the spreadsheet object 605 subsequently enters the running 
state, if the information indicates a link was requested 

35 at least once, then the spreadsheet object 605 is 
registered in the running object table. 
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Figures 7 through 12 are flow diagrams 
illustrating the automatic connection techniques of the 
present invention. Figure 7 is a flow diagram 

illustrating how a process registers objects as running or 
5 alert, establishes a connection, and revokes the 
registration of objects when the object leaves the alert 
or running states. A process acts as a consumer process 
when an object in the running state contains a link object 
and acts as a source process when an object in the running 

10 state is a link source. In a preferred embodiment, 
existing computer programs can be modified or new computer 
programs can be developed in accordance with the flow 
diagram. These computer programs can then function as 
consumer and source processes as described below. in 

15 steps 701, 702A, and 702B, the process opens an object, 
invokes a routine to register the object as running, and 
invokes a routine to register contained link objects as 
alert. In step 701, the process opens an object, which 
puts the object in the running state. In step 702A, the 

20 process invokes routine BeginRunning passing it the opened 
object to register the object in the running object table. 
The routine BeginRunning is invoked whenever an object 
enters the running state. In step 702B, the process 
invokes the routine RegisterLinkObjects passing it the 

25 opened object. The routine RegisterLinkObjects registers 
in the alert object table the link objects in the opened 
object when the corresponding source objects are not in 
the running state. The ellipses indicate that the process 
continues with its normal processing. Steps 705 through 

30 707 represent a message loop for receiving notification 
that an object enters the running state. When a process 
receives such notification, the process processes the 
notification in steps 706 and 707, In steps 705 through 
707, the process acting as a consumer process receives a 

35 message from a source process indicating that a link 
source is now in the running state, establishes a 
connection with the source process, and revokes the 
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registration of the corresponding link object. In step 
705, the process receives notification from a source 
process that puts the link source corresponding to a link 
object that is registered in the alert object table in the 
5 running state. In step 706, the process establishes a 
connection with the source process. In step 707, the 
function invokes function RevokeAsAlert passing it the 
link object. The function RevokeAsAlert removes the entry 
corresponding to the link object from the alert object 

10 table. Steps 708 through 710 are executed when an object, 
such as a compound document, is closed (exits the running 
state) . In steps 708 through 710, the process revokes all 
registrations for the opened object, closes any 
connections to source processes, and closes the object, 

15 which puts the object in the passive state. In step 708, 
the process invokes function Revoke passing it the opened 
object. In step 709, the process closes all connections 
to source processes. In step 710, the source closes the 
opened object. 

20 Figure 8 is a flow diagram of the function 

Regis terLinkObjects. This function is passed an object 
and registers all contained link objects in the alert 
object table. All link objects within any contained 
object to any level of nesting are also registered in the 

25 alert object table by recursively invoking this routine. 
In steps 802 through 806, the function loops registering 
each contained object by calling the function 
Regis terlnAOT for link objects or by recursively calling 
the function RegisterLinkObject for non-link objects. In 

30 step 802, the function selects the next contained object, 
starting with the first contained object. In step 803, if 
all contained objects have already been selected, then the 
function returns, else the function continues at step 804. 
In step 804, if the selected object is a link object, then 

35 the function continues at step 806, else the function 
continues at step 805 . In step 805 , the function 
recursively invokes function Regis terLinkObjects passing 
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it the selected object. The function then loops to step 
802. In step 806, the function invokes the function 
Regis terlnAOT to register the selected object in the alert 
object table. The function then loops to step 802. 
5 Figure 9 is a flow diagram of the function 

BeginRunning. The function BeginRunning is passed an 
object and registers the object identifier in the running 
object table. In step 901, the function invokes function 
RegisterlnROT to add an entry into the running object 

10 table for the source object link source identifier. In 
steps 902 through 905, the function sends a message to 
each link object that is awaiting notice of the running of 
the link source identified by the object identifier. In 
step 902, the function selects the next entry in the alert 

15 object table starting with the first entry. In step 903, 
if all entries in the alert object table have already been 
selected, then the function returns, else the function 
continues at step 904. In step 904, if the object 
identifier matches the link source identifier in the 

20 selected entry, then the function, in step 905, sends 
notification to the link object identified by the link 
object identifier of the selected entry. The function 
then loops to step 902. 

Figure 10 is a flow diagram of the function 

25 RegisterlnROT. The function RegisterlnROT is passed a 
link source identifier and a link source pointer, 
determines if the link source identifier is already in the 
running object table, and if not, stores an entry for the 
link source identifier in the running object table. In 

3 0 step 1001, the function invokes function IsRunning to 
determine whether the link source identifier is already in 
the running object table. The function IsRunning searches 
the running object table and returns a flag indicating 
whether the object is already in the table. In step 1002, 

35 if the link source identifier is already in the running 
object table, then the function returns, else the function 
continues at step 1003. In step 1003, the function adds 
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an entry for the link source identifier to the running 
object table. 

Figure 11 is a flow diagram of the function 
RegisterlnAOT. The function RegisterlnAOT is passed a 
link object identifier and its corresponding link source 
identifier and determines whether the link source is 
already running. if so, the function establishes a 
connection, else it adds an entry to the alert object 
table. in step 1101, the function invokes function 
IsRunning to determine whether the corresponding link 
source identifier is in the running object table. In step 

1102, if the link source identifier is in running object 
table, then the function establishes a connection in step 

1103, else in step 1104 the function adds an entry to the 
15 alert object table for the passed link object identifier. 

The function then returns. 

Figure 12 is a flow diagram of the function 
Revoke. The function Revoke inputs an object and removes 
the entry corresponding to the object and its contained 
20 objects from either the running or alert object table. In 
step 1201, the function invokes the function 
RevokeAsRunning passing it the link source identifier of 
the passed object. The function RevokeAsRunning removes 
the entry corresponding to the link source identifier from 
25 the running object table if it is in the table. In steps 
12 02 through 1206, the function loops revoking each 
contained object by calling the function RevokeAsAlert for 
link objects or by recursively calling the function Revoke 
for non-link objects. In step 1202, the function selects • 
3 0 the next contained object, starting with the first 
contained object. In step 1203, if all contained objects 
have already been selected, then the function returns, 
else the function continues at step 1204. In step 1204, 
if the selected object is a link object, then the function 
continues at step 1206, else the function continues at 
step 1205. In step 1205, the function recursively invokes 
function Revoke passing it the selected object. The 
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function then loops to step 1202. In step 1206, the 
function invokes the function RevokeAsAlert to remove the 
entry corresponding to the selected object from the alert 
object table. The function then loops to step 1202. 
5 It will be appreciated that, although specific 

embodiments of the invention have been described herein 
for purposes of illustration, various modifications may be 
made without departing from the spirit and scope of the 
invention. Accordingly, the invention is not limited 
10 except as by the appended claims. 
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Claims 

1. A method executed in a computer system for 
establishing a connection between a link source and a link 
object, the method including the steps of: 

executing a source process wherein the source 
process puts the link source in a running state,* 

executing a consumer process wherein the consumer 
process puts the link object in an alert state, the link 
object having a reference to the link source; and 

connecting the link object to the link source upon 
an occurrence of both putting the link source in the running 
state and putting the link object in the alert state. 

2. The method of claim l, further comprising the 

step of : 

registering the link object in an alert object table 
by storing a reference to the link object and an identifier of 
the link source in the alert object table so that the step of 
connecting the link object and the link source is performed 
when the link source enters the running state. 

3. The method of claim 2, further comprising the 

step of: 

determining if the link object is in the alert state 
by comparing for equivalence of the link source identifier 
stored in the alert object table with a link source identifier 
when the link source is put in the running state. 

4. The method of claim 1, further comprising the 

step of: 

registering the link source in a running object 
table by storing the link source identifier in the running 
object table so that the step of connecting the link object 
and the link source is performed when the link object is put 
in the alert state. 
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5. The method of claim 4, further comprising the 

steps of: 

determining if the link source is in the running 
state by comparing for equivalence the link source identifier 
stored in the running object table with a link source 
identifier when the link object is put in the alert state. 

6. The method of claim 1, wherein the link source 
having a native representation of data further comprising the 
steps of: 

modifying the native representation of the data of 
the link source; and 

notifying the link object of the modifications 
through the connection so that the modifications can be 
reflected in the consumer process. 

7. A method in a computer system for connecting a 
link object to a link source, the method comprising the steps 

Of: 

registering the link source in a running object 

table when the link source is put in a running state; and 

when a link object enters an alert state, 

determining if the link source is registered in the running 

object table and connecting the link object to the link source 
upon such a determination. 

8 . A method in a computer system for connecting a 
link object to a link source, the method comprising the steps 

Of: 

registering the link object, in an alert object table 
when the link object enters an alert state; and 

when the link source enters a running state, 
determining if the link object is registered in the alert 
object table and connecting the link object to the link source 
upon such a determination. 



WO 94/11817 



PCT/US93/10854 



19 

9. A computer system for connecting a link object 
to a link source comprising: 

a running object table; 

means for registering the link source in the running 
object table when the link source enters a running state; and 

means for determining if the link source is 
registered in the running object table and connecting the link 
object to the source object upon such a determination when the 
link object enters an alert state. 

10. A computer system for connecting a link object 
to a link source comprising: 

an alert object table; 

means for registering the link object in the alert 
object table when link object enters an alert state; and 

means for determining if the link object is 
registered in the alert object table when the link source 
enters a running state and connecting the link object to the 
link source upon such a determination. 

11. A method executed in a computer system for 
notifying a link object that a link source has been placed in 
a running state, the method comprising the steps of: 

placing the link object in an alert state; 

after placing the link object in the alert state, 
placing the link source in the running state; and 

after placing the link source in the running state, 
notifying the link object that the link source has been placed 
in the running state. 



12. The method of claim 11, further comprising the 
step of after notifying the link object, placing the link 
object in the running state. 
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